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ABSTRACT 

Space Shuttle Main Engine (SSME) maintenance, whether preventive, scheduled, or 
unscheduled, is a major escalating cost item. Significant progress has been made in the NASA 
and Air Force communities toward performance of the health monitoring function in 
instrumentation, analysis techniques, and envelope (trends and rate of change) monitoring. 
Current techniques require that domain experts be integrally involved in the analysis session and 
make on-line decisions to direct analysis. The SPARTA Embedded Expert System (SEES) is an 
intelligent health monitoring system that directs the analysis by placing confidence factors on 
possible engine status, then recommends a course of action to an engineer or the engine 
controller. This technique can prevent catastrophic failures or costly rocket engine down time 
because of false alarms. Further, the SEES has potential as an on-board flight monitor for reusable 
rocket engine systems. The SEES methodology synergistically integrates vibration analysis, 
pattern recognition, and communications theory techniques with an artificial intelligence 
technique - the Embedded Expert System (EES). This integration affords a robustness via the 
analysis techniques with an ability to resolve conflicts by the expert system techniques. 

INTRODUCTION 

A critical element of the Space Shuttle Main Engine (SSME) program is the development of a 
turbo-pump health monitoring system (HMS). A HMS that could predict incipient failures and 
permit routine maintenance to be scheduled based on performance indicators would dramatically 
reduce the need for refurbishment, improve equipment availability, and make maintenance more 
cost-effective. The key functions of an effective HMS are shown in Figure 1 . 


RECOGNIZE AND CATEGORIZE PERFORMANCE 
(Baselining Of Performance Standards) 

RECOGNIZE AND CORRELATE INDICATORS OF IMPENDING 
FAILURE 

(Incipient Failure Prediction) 

RECOGNIZE AND CORRELATE INDICATORS OF NEED FOR 
REMEDIAL ACTION 

(Scheduling Of Routine Maintenance In A Cost-Effective 
Manner) 


Figure 1. HMS ESSENTIAL FUNCTIONS 
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Siqnificant progress has been made in the NASA community toward performance of the 
HMS functions. There have been relevant advances in instrumentation [4,1], analysis techniques 
[2 51 and in detection of anomalies and failures [3]. Each of these advances has demonstrated 
individual attributes useful for an HMS to correlate failure modes with turbo-pump components at 
risk However, an integrated HMS that uses and updates the SSME data base is possible through 
the use of emerging Al techniques. Al techniques, specifically a rule-based expert system can 
enhance the functions of an HMS. SPARTA has developed and adapted a set of a gonthms to 
produce an innovative application of Artificial Intelligence techniques. The keystone of this 
application is an expert system that uses confidence levels to resolve conflicts among compound 
data and that heuristically trains on each data set to derive (or modify) classification rules. This 
expert system has been named SEES, an acronym for SPARTA Embedded Expert System. 

SEES ARCHITECTURE 

The SEES architecture is shown in Figure 2. In SEES, conventional computation methods 
are used to reduce the raw data to a manageable "derived" data set, and to extract pertinent 
information (signatures) from the derived data set. This information is then used by the SEES to 
derive rules, with the help of domain experts/knowledge engineers, to establish a knowledge 
base. In future phases, SEES will use this set of rules to determine engine conditions during 

SSME testing. 

MAJOR COMPONENTS 

As can be seen from the architecture in Figure 2, there are three major subsystems to the 
SEES HMS: The SEES front end (SFE), the embedded expert system (EES), and the 

supportfunction library (SFL). The SFE processes the raw data to screen obvious anomalies and 
to derive the reduced data set, then generates from it an appropriate signature. The process of 
data screening, reduction and signature generation is the unique and proprietary innovation of 
SEES. The embedded expert system (EES) uses this signature and the reduced data, with the 
help of the SFL and the rule set in its knowledge base, to infer the operating conditions at a given 
instant, deduce the mean time to failure and recommend maintenance schedules. The SFL, as its 
name implies, is a set of supporting functions for the rest of the HMS. 


SEES FRONT END (SFE) 

The SFE is comprised of signal analysis techniques that convert raw count accelerometer 
data to Engineering Units and transform the data to the frequency domain using Fast Fourier 
Transforms (FFT) to derive a power spectral density (PSD) for input to a Data Conditioning Module. 
The Data Conditioning Module processes the PSD signal to remove the extraneous components. 
Finally the conditioned PSD is evaluated as a candidate for signatures derived during this 
processing (by the Pattern Matcher) or binned to be considered for establishment of another 

signature. 


SEES SUPPORT FUNCTION LIBRARY (SFL) 

The SFL consists of the algorithms that transform reduced data into symbol structures for 
use by the Development Engine and/or the Inference Engine to accomplish inference and control. 
This transformation is accomplished by applying communications theory and image processing 
methods to the SFE conditioned data. 


SEES EMBEDDED EXPERT SYSTEM 

The Embedded Expert System (EES) is an integral part of the HMS. The EES is a rule based 
knowledge system that uses forward chaining strategy, and has the ability to recognize and 
categorize performance, incipient failure and the need for remedial action. It consists of a 
development engine, a knowledge base, an inference engine, and a user interface. 
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The Development Engine 


The development engine is a subsystem of EES which is intimately related to the knowledge 
acquisition process; it allows a knowledge engineer to transcribe the knowledge gained from the 
domain expert into a set of rules that make up the knowledge base. A basic characteristic of the 
SEES problem in analyzing SSME vibration data is the volatility of signatures and the importance 
of high rate vibration data. While some rules can be developed, the evaluation of data in real-time 
leads to the requirement to merge information from multiple sources. This leads to the use of the 
blackboard architecture for storing intermediate hypotheses, the use of a certainty factor merging 
heuristic and rule-use counting as a "rule-critic". 

The SEES Knowledge Base 

Based on SPARTA's study of the training sets, we expect the knowledge base to be quite 
large. Our investigation indicated that signatures may be extracted and meaningfully classified. 
Thus, the rule set may be ordered in an appropriate manner (e.g., a rule tree) to reduce search 
space. The nature of the data is such that one can seldom specify a diagnosis with absolute 
certainty. Thus in SEES, certainty factors will be used to reflect uncertain information. These 
certainty factors can be either computed algorithmically by the development engine based on 
derived or existing knowledge, or estimated by domain experts or knowledge engineers. 

The SEES Inference Engine 

The SEES HMS is basically data driven. Thus, a forward chaining strategy is appropriate. 
The incoming data, although reduced by the SFE, is still quite complex, and entering the HMS at a 
high rate. The EES inference engine must and will have the capability to invoke functions in the 
SFL for further data reduction. Perhaps one of the more important tasks of the inference engine is 
to determine when an unknown situation (i.e., not in the rule base) occurs. It should be able to 
coordinate with the domain expert or knowledge engineer and pass the new information to the 
development engine to create new rules, or store the information to accomplish the same at a later 
time off-line when a domain expert is available. The inference engine must provide information to 
the explainer to produce explanation on demand. The explainer is a subsystem of the user 
interface and can provide explanations as to how a conclusion is reached. This can be 
accomplished in a variety of ways; the one selected by SPARTA is to leave the time history of 
SEES events in the blackboard for post mortem examination. 

SEES User Interface 

The user interface is the component of an expert system that acts as an interface between 
the expert system and the user who is not necessarily a domain expert. Thus, it should have the 
capabilities to: (1) Solicit input from the user, (2) Provide output to the user - this output may be in 
the form of questions, recommendations or conclusions, and (3) Provide explanations on 
demand. One important aspect that can be implemented is a possible data link between the user 
interface and the SSME controller. This would serve as a means to assume control of the engine in 
unusual situations, such as when an imminent engine failure has been detected, and an immediate 
engine shutdown becomes necessary to prevent catastrophic failure. This feature is, of course, 
not needed for off-line testing. 

IMPLEMENTATION 

Preliminary investigation to date has been carried out using a VAX780 computer in 
FORTRAN. It is anticipated that the final system will be implemented in FORTRAN or C to run on a 
MASCOMP computer. This computer is chosen because of the outstanding data acquisition 
capabilities which is a critical aspect of SEES. Equally important is the fact that a variety of 
languages and utilities are available commercially for this micro-supercomputer. A decision has to 
be made as to the language used to develop the embedded expert system (EES). One can 
choose the more traditional approach of using LISP or PROLOG (both of which are available to the 
MASCOMP, and both can interface with the rest of the system if it is written in C. We have decided 
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to use RULE MASTER by Radian Corporation. This is an expert system shell that would allow us to 
develop EES rapidly, and can be integrated to the rest of SEES easily. 


PRELIMINAR Y RESULTS 

The vibration time series is analyzed in a discrete data format. The data is first transformed 
into a power spectral density (PSD). Each discrete PSD is the power average over a small time 
interval at a frequency with a certain bandwidth. The power level of a frequency line is then 
temporalized. Figure 3 shows the amplitude time history of one important frequency band. The 
accompanying SSME power profile shows the shift from 100% to 104% power level. The 
amplitude of the time history shows a marked decrease at that time. Other bands show an increase 
at ramp up to 104%. The characterized signatures consist of a covariance matrix, C, which 
measures coupling between components of the sample vectors and the mean sample vector M. 
A siqnature is a measure of the turbo-pump's performance profile at a given load condition. When 
a turbo-pump is operated at a load condition for an extended period, its performance may degrade 
from nominal to anomalous. This degradation is measured by the HMS and characterized into a 
class ensemble of signature, at a load condition. Two signatures characterized from the SSME test 
are presented in Figure 4. The spectral components of these signatures are very complicated; 
therefore, Al techniques must be used to classify data. 

CONCLUSIONS 


Preliminary analysis has shown that the SEES development engine successfully extracts 

signatures from SSME test data that can be formulated into rules for the SEES knowledge base. 
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FIGURE 2. SEES - HMS ARCHITECTURE 
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FIGURE 3. TEMPORALIZED DATA OF CHANNELS FROM SSME TEST #A2-356-5042 
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FIGURE 4. TYPICAL SSME SIGNATURES 
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